Financial Inclusion Card, System, and Method for Implementing

ABSTRACT

Embodiments of the invention are directed to a computer-implemented financial inclusion account system and method provided by a financial institution for facilitating payments between system participants, the system participants including account holder service recipients and eligible necessities service providers. The system includes at least one financial inclusion account maintaining funds for an account holder service recipient. The financial inclusion account includes a main account having a main account balance and at least one sub-account having a sub-account balance, the at least one sub-account storing funds for payment to at least one eligible necessities service provider. The system additionally includes withdrawal rules stored in a memory, the withdrawal rules including identification of approved debit requesters for withdrawing funds from the sub-account balance, the withdrawal rules requiring approved debit requesters to be debit requestors designated by the financial institution as eligible necessities service providers. The system additionally includes a withdrawal engine for accessing the stored withdrawal rules upon receiving a debit request, the withdrawal engine causing the sub-account balance to be debited if the debit requester is an approved debit requestor according to the stored withdrawal rules.

This application is a continuation-in-part application of U.S. patentapplication Ser. No. 10/011,971, filed on Dec. 11, 2001.

TECHNICAL FIELD

Embodiments of the invention are related generally to systems andmethods for financial account administration and management.

BACKGROUND OF THE INVENTION

In many countries, the government provides benefits to individualshaving limited resources and allows these benefits to be used forpayment of necessities. Currently, in some countries, the governmentsponsors accounts for benefits recipients, in which the governmentdeposits funds to assist the benefits recipients with payments fornecessities such as for example, utilities or food. The governmentsponsored accounts may be recharged on a regular basis, such as on amonthly basis.

An Electronic Benefit Transfer (EBT) system has developed and iscurrently being used in many states in the United States to issue foodstamp and other benefits. In an EBT system, the benefits recipients mayreceive a plastic debit card for use at participating retailers. Foodstamp benefits can be used only to purchase food items authorized by theUSDA's Food Stamp program. Cash benefits may be used to purchase anyitem at a participating retailer, as well as to obtain cash-back or makea cash withdrawal from a participating ATM.

For example, in the food stamp program, food stamp recipients apply fortheir benefits in the usual way, by filling out a form at their localfood stamp office. Once eligibility and level of benefits have beendetermined, information is transferred to the state's EBT contractor, anaccount is established in the participant's name, and food stampbenefits are deposited electronically in the account each month. Aplastic debit card, similar to a bank card, is issued and a personalidentification number (PIN) is assigned or chosen by the recipient togive access to the account.

When paying for groceries, the food stamp customer's card is run throughan electronic reader or a point of sale terminal (POS), and therecipient enters the PIN to access the food stamp account. The processorelectronically verifies the PIN and the account balance, and sends anauthorization or denial back to the retailer. The recipient's account isthen debited for the amount of the purchase, and the retailer's accountis credited. Payment is typically made to the retailer through asettlement process at the end of the business day, such as by a directdebit request through an Automated Clearinghouse (ACH) transaction.

In the United States, direct debit usually means an ACH transfer from abank account to a biller, initiated by the biller. Businesses are alsoincreasingly using ACH to collect from customers online, rather thanaccepting credit or debit cards. Direct debiting allows an organizationto instruct its bank to collect varying amounts directly from customers'accounts, using an electronic funds transfer.

Direct debits may be executed through the use of a debit card, oralternatively upon request by a biller having authorization from anaccount holder. The authorization may be for a single transaction or formultiple recurring transactions. Thus, service providers may instructthe service provider bank to collect an amount from the account of thebenefit recipient through electronic funds transfer. The customer orbenefits recipient may instruct his or her bank to honor debit notesfrom the service provider. Before a company can set up direct debitsfrom its customers, it has to be authorized in order to prevent fraudand to ensure that the proper controls are in place. Companies wishingto use direct debits to collect customer payments may be granted anidentification number. Direct debit payments may typically be set up viapaper-based forms requiring a signature of the account holder, viatelephone, or via the internet using an online application form.

Although direct debit arrangements may vary within countries and betweendifferent countries, organizations may be required to enter into adirect contract with their banks. The collecting organization may berequired to present an authorization to the accountholder's bank, uponrequest. If the authorization cannot be presented, the direct debittransaction may not be honored.

Direct debit plans are beneficial to participating merchants as themerchants are guaranteed government payment for goods and services forwhich they might otherwise not be reimbursed. For benefits recipients inthe UK, this direct debit currently is drawn from the governmentsponsored accounts. Thus, in some countries, benefits recipientsauthorize providers of the necessities, such as utility companies,grocers, or other merchants to transfer funding for the necessities fromthe government sponsored account to the provider account. In fact, insome countries, providers such as utility companies provide a discountto customers who execute payments through direct debit rather thanthrough checking, credit, or other methods.

However, sponsoring such accounts results in additional burden andexpense for governments. The government typically assumes allresponsibility and expense for maintaining the accounts, and theindividuals benefitting from the accounts have no similarresponsibilities. Furthermore, in many countries, governments areminimizing benefits to individuals and therefore are encouragingindividuals to take more responsibility.

Banking institutions have a desire to retain customers and funds andthus likewise have an interest in continued existence of these accountsholding funds for benefits recipients. However, simply providingaccounts to benefits recipients does not guarantee that the utilitycompanies and other necessities providers will be able to easily accessthe benefits funds.

If the government chooses to limit its involvement in providingfinancial benefits for payment of necessities by curtailing theprovision of accounts and merely providing funds directly to recipients,then recipients would be forced to assume greater responsibility forfinancial management. However, for individuals living without excessavailable funds, minor errors in financial management can create majordifficulties with respect to payment for essentials.

Accordingly, a solution is needed that will relieve government burdenand transfer more account maintenance responsibility to individualsand/or providers of goods and services who benefit from secure andguaranteed payment from individuals receiving benefits. A solution isfurther needed that will facilitate management of funds by benefitsrecipients or other individuals having difficulty paying for basicnecessities and minimize the expense to the individuals for thesenecessities.

SUMMARY OF THE INVENTION

In one aspect of the invention, a computer implemented financialinclusion account system is provided by a financial institution forfacilitating payments between system participants. The systemparticipants include account holder service recipients and eligiblenecessities service providers. The system includes at least onefinancial inclusion account that maintains funds for an account holderservice recipient, the financial inclusion account includes a mainaccount having a main account balance and at least one sub-accounthaving a sub-account balance. The sub-account stores funds for paymentto at least one eligible necessities service provider. Withdrawal rulesstored in a memory include identification of approved debit requestersfor withdrawing funds from the sub-account balance. The withdrawal rulesrequire approved debit requesters to be debit requesters designated bythe financial institution as eligible necessities service providers. Awithdrawal engine is provided for accessing the stored withdrawal rulesupon receiving a debit request and the withdrawal engine causes thesub-account balance to be debited if the debit requester is an approveddebit requestor according to the stored withdrawal rules.

In another aspect of the invention, a computer-implemented financialinclusion account management method is provided by a financialinstitution for facilitating payments between system participants. Thesystem participants include account holder service recipients andeligible necessities service providers. The method includes establishingat least one financial inclusion account maintaining funds for anaccount holder service recipient, the financial inclusion accountincluding a main account having a main account balance and at least onesub-account having a sub-account balance. The sub-account stores fundsfor payment to at least one eligible necessities service provider. Themethod additionally includes storing withdrawal rules in a memory, thewithdrawal rules including a listing of approved debit requestorswherein approved debit requesters have been designated by the financialinstitution as eligible necessities service providers. The methodfurther includes accessing the stored withdrawal rules through the useof a withdrawal engine upon receiving a debit request. The withdrawalengine causes the sub-account balance to be debited if the debitrequestor is an approved debit requester.

In yet an additional aspect of the invention, a computer-implementedfinancial inclusion account system for facilitating payments betweensystem participants is provided. The system participants include servicerecipients and eligible necessities service providers. The systemcomprises at least one financial inclusion account, the financialinclusion account including a main account having a main account balanceand at least one sub-account having a sub-account balance. Thesub-account stores funds for payment to at least one eligiblenecessities service provider. The system additionally includes afinancial inclusion account management system for managing the at leastone financial inclusion account. The management system comprises awithdrawal engine and a deposit engine. The deposit engine accessesstored deposit rules in order to determine a main balance deposit amountof a submitted deposit to credit to the main balance and a sub-accountdeposit amount of the submitted deposit to credit to the sub-account.The withdrawal engine comprises authorization components for consultingwithdrawal rules to determine if a debit requester is an approved debitrequester for withdrawing funds from the sub-account. Each approveddebit requester is designated by the financial institution as aneligible necessities service provider. A withdrawal module is providedfor executing withdrawal from the sub-account for approved debitrequestor.

A computer-implemented financial inclusion account management method isprovided for facilitating payments for approved services between systemparticipants, the system participants including service recipients andapproved necessities service providers. The account management methodincludes providing at least one financial inclusion account, thefinancial inclusion account including a main account having a mainaccount balance and at least one sub-account having a sub-accountbalance, the at least one sub-account storing funds for payment to atleast one approved necessities provider. The method further includesmanaging deposits and withdrawals to and from the financial inclusionaccount. The management of deposits includes storing deposit rules, andaccessing the stored deposit rules upon receiving a deposit in order todetermine a main balance deposit amount of a submitted deposit to creditto the main balance and a sub-account deposit amount of the submitteddeposit to credit to the sub-account. The management of depositsadditionally includes executing the stored deposit rules to credit thesubmitted deposit to at least one of the main balance and thesub-account balance. The management of withdrawals includes storingwithdrawal rules for determining approval for executing withdrawals fromthe sub-account and consulting the withdrawal rules to determine if adebit requestor is an approved debit requester for withdrawing funds,wherein each approved debit requester is designated by the financialinstitution as an eligible necessities service provider. The managementof withdrawals additionally includes executing withdrawals from thesub-account for approved debit requestors.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described in detail below with reference to theattached drawings figures, wherein:

FIG. 1 is a block diagram illustrating an operating environment for afinancial inclusion account system in accordance with an embodiment ofthe invention;

FIG. 2 is a block diagram illustrating components of a financialinclusion account system in accordance with an embodiment of theinvention;

FIG. 3 is a block diagram illustrating a deposit engine of the financialinclusion account system in accordance with an embodiment of theinvention;

FIG. 4 is a block diagram illustrating a withdrawal engine of thefinancial inclusion account system in accordance with an embodiment ofthe invention;

FIG. 5 is flow chart illustrating a method for making deposits into afinancial inclusion account in accordance with an embodiment of theinvention;

FIG. 6 is a flow chart illustrating a method for paying direct debitsfrom the financial inclusion account in accordance with an embodiment ofthe invention;

FIG. 7 is a diagram illustrating a stored withdrawal rule table inaccordance with an embodiment of the invention;

FIG. 8 is block diagram illustrating a stored deposit rule table inaccordance with an embodiment of the invention; and

FIG. 9 is a block diagram illustrating a service provider billingmanagement system in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Embodiments of the present invention are directed to a financialinclusion account system for facilitating management of funds allottedfor necessities as well as a method for efficiently reserving andproviding the allotted funds to necessities providers.

Embodiments of the invention have the technical effect of efficientmaintenance and rapid and reliable electronic transfer of funds in orderto relieve government burden and facilitate payments to necessitiesproviders.

FIG. 1 is a block diagram illustrating an operating environment for afinancial inclusion account system 200 in accordance with an embodimentor the invention. A service recipient financial institution 120 may beconnected over a network 50 with service provider financial institutions10 a . . . 10 n. Each service provider financial institution may provideaccount services for multiple service providers 20 a . . . 20 n and 30 a. . . 30 n. Each service recipient financial institution 120 may providefinancial services to service recipients 100 a . . . 100 n. Thefinancial inclusion account system 200 may be operated by the servicerecipient financial institution 120.

Additionally, one or more benefits providers 60 may have a relationshipwith the service recipients 100 a . . . 100 n and/or service recipientfinancial institution 120. In embodiments of the invention, the benefitsprovider. 60 may directly deposit funds into the financial inclusionaccount system 200. Alternatively, the benefits provider 60 may providebenefits directly to the service recipients 100 a . . . 100 n so thatthe service recipients 100 a . . . 100 n may deposit the benefits intotheir accounts. Although the benefits provider 60 is shown as connectedover the network 50, the benefits provider 60 may access the benefitsrecipient in another manner, such as by mailing a paper check (orchecque).

Clearing and settlement mechanisms 40 operate to facilitate direct debitrequests. These clearing and settlement mechanisms 40 may enable ACHtransactions over an electronic transfer network (ETN). An ACH entrystarts with an account holder 100 a . . . 100 n authorizing anoriginator or service provider 20 a . . . 20 n to issue ACH debit orcredit to an account. To execute an ACH transaction, the account holder100 a . . . 100 n then creates an ACH entry to be given to the servicerecipient financial institution 120. This ACH entry is then sent to anACH Operator of the clearing and settlement mechanisms 40 and is passedon to the service provider financial institution 10 a . . . 10 n, wherethe service provider's account is issued either a credit or debit,depending on the ACH transaction.

FIG. 2 is a block diagram illustrating components of a financialinclusion account system 200 in accordance with an embodiment of theinvention. Service recipients 100 a . . . 100 n may maintain financialinclusion accounts 210 a . . . 210 n. Each account 210 a . . . 210 n mayinclude a main account 220 and a necessities sub-account 230. Theprovision of sub-accounts is discussed in co-pending U.S. patentapplication Ser. No. 10/011,971, of which the present application is acontinuation-in-part application. The description provided in theearlier application is incorporated herein by reference. The accounts210 a . . . 210 n may be operated by a financial inclusion accountmanagement system 240. The financial inclusion account management system240 may include a withdrawal engine 300 and a deposit engine 400.

The financial inclusion accounts 210 a . . . 210 n may resemble ordinarycard based accounts but also have the sub-account 230 associated withthem specifically for facilitating saving to pay bills, such as utilitybills. In embodiments of the invention, on a regular basis, usingpre-defined rules, either at pre-set times or as funds are credited tothe main account 220 a . . . 220 n, funds are transferred from the mainbalance into the sub-account balance, as will be further describedbelow. This process gradually builds a fund to pay utility bills as theyfall due.

The accounts 210 preferably maintain a main balance in the main account220 that is generally accessible to the account holder and debitrequesters authorized by the account holder. When an account holdermakes a deposit or receives a deposit from another party without anyspecific designation, the received deposit will be credited to the mainbalance. Furthermore, any direct debit requests without specificauthorization for retrieving funds from the sub-account will have itsauthorization verified to debit funds from the main account balance.

As will be further explained below, the necessities sub-account 230receives funds as dictated by the account holder. Additionally,authorized debit requestors may execute direct debits from thenecessities sub-account balance. For the necessities sub-accountbalance, only pre-determined necessities providers may be authorized toexecute direct debits. In order to become authorized, the servicerecipient financial institution must first determine that the providersare eligible for authorization.

For example, while some providers, for example utilities providers andgrocers, may eligible for authorization to execute a direct debittransaction from the necessities sub-account, other providers, such ascable television service providers will not be eligible forauthorization as cable television is generally not considered anecessity. Utilities providers may for example include electriccompanies, gas companies, water and sewer providers, trash removalproviders, and telephone service providers. However, this list is merelyexemplary and may vary regionally in accordance with local needs anddeterminations.

If a financial institution determines that a provider is eligible to beincluded on a list of authorized service providers, the financialinstitution may require account maintenance fees to be covered by thatprovider in order to shift the cost from the individual account holders,who are typically individuals with limited resources. The amount of thefee may be determined by the financial institution and may for examplebe based on the number of accounts to which the eligible serviceprovider obtains access for debit requests. Alternatively, each eligibleservice provider may be charged an identical fee. The fee may beassessed periodically, for example monthly or yearly. As a furtheralternative, the fee may be charged on a per debit basis.

Furthermore, each individual account holder may authorize only a subsetof those eligible for authorization. “Eligibility” and “authorization”are two separate and distinct requirements for approval of the debittransaction. Eligibility settings are maintained by the financialinstitution and may be determined in a number of different ways. Forexample, the eligibility settings may be determined by the financialinstitution either independently, or in accordance with applicableregulations, or in cooperation with other entities, such as providers orlocal governments. As set forth above, eligibility determination will belinked to the type of service provided and whether such servicequalifies as a necessity. “Authorization” is determined by accountholders. Presumably, financial inclusion account holders would authorizedirect debits from a financial inclusion sub-account only for entitiesactually providing the account holder with services. If an accountholder does not receive services from providers having eligibility, theaccount holder will not grant authorization to those providers.Furthermore, financial inclusion account holders may prioritize suchthat only providers of certain necessities will receive authorization.

Additionally, the “authorization” provided by the account holder forexecuting a debit from the sub-account is separate and distinct from thegeneral authorization that is typically required for execution of an ACHtransaction. This general authorization merely entitles a debitrequestor to execute a debit from an account holder's main accountbalance and not from the sub-account.

Thus, once an account holder has deposited money into the necessitiessub-account, the funds in the sub-account are available to a smallnumber of providers who are both eligible as determined by the servicerecipient financial institution, and authorized as determined by theaccount holder.

The financial inclusion accounts 210 are maintained in many cases forservice recipients who may not otherwise have bank accounts. Severaloptions may be available for opening financial inclusion accounts 210.For example, the accounts may be initiated for benefits recipients bybenefits providers. Alternatively, benefits providers may provideinformation to benefits recipients and the benefits recipients mayassume responsibility for establishing a relationship with the bankproviding the financial inclusion accounts. As a further alternative,the bank providing the financial inclusion accounts may provide an offerto benefits recipients and/or to the general population of servicerecipients for establishing a financial inclusion account. In furtherembodiments or the invention, the service providers 20 may extend aninvitation to selected recipients to open such an account. The serviceproviders 20 may identify target service recipients by reviewing thepayment histories of service recipients for difficulties over time todetermine if recipients would benefit from establishing a financialinclusion account.

In order to initiate such a system, utilities companies or othernecessities providers may approach potential customers and offer areduced rate for implementation of the financial inclusion accountsystem. In order to gain access to the financial inclusion accounts,companies may request information from the customer.

In embodiments of the invention, the service recipient financialinstitution may operate as an information broker by providing necessaryaccount information to the service recipient account holders.Additionally, the service providers will be required to subscribe withthe service provider financial institution and have eligibilityconfirmed.

The service recipient account holders may then provide the informationto the applicable necessities providers. In embodiments of theinvention, the necessities providers may require a periodic depositamount from the service recipients into the necessities sub-account inorder to allow service recipient participation in the reduced-rateprogram.

For the service recipients, the enrollment process may take any numberof forms, but would likely be initiated by a paper transaction.Similarly, while most transactions may be performed electronically,known paper-based methods may also be implemented.

Although the system is shown as including benefits providers, servicerecipients who don't receive benefits from the benefits providers mayalso be eligible to participate in the reduced-rate program. Necessitiesproviders can identify problem customers without knowing if thecustomers are benefit recipients.

FIG. 3 is a block diagram illustrating a deposit engine 300 of thefinancial inclusion account system 200 in accordance with an embodimentof the invention. The deposit engine 300 may include depositorverification components 310, deposit distribution components 320, andstored deposit rules 330. In operation, the depositor verificationcomponents 310 may access stored deposit rules 330. Additionally, thedeposit distribution components 320 may access the stored deposit rules330 in order to determine appropriate distribution of deposited funds.

The depositor may for example be an employer that deposits payrollchecks to the account holders account. Alternatively, the account holdermay be the depositor. As a further alternative, the depositor may be agovernment agency or other benefits provider providing direct deposit ofbenefits. As yet an additional possibility, the depositor may be anindividual or corporate entity transferring a payment for an itempurchased from the account holder or for a debt owed to the accountholder.

The depositor verification components 310 may ascertain the identity ofthe depositor. When establishing the account, the account holder maydetermine, based on the identity of the depositor, what percentage oramount of the deposited funds should be credited to the main accountbalance and what percentage or amount of the deposited funds should becredited to the necessities sub-account balance. For example, in thecase of a government depositor, the account holder may determine that100% of the deposited funds may be allocated to the necessitiessub-account. In some embodiments, the financial institution and/orservice provider may encourage direct deposit to the necessitiessub-account and may in some instances provide incentives for depositinga larger percentage of funds in the necessities sub-account.Furthermore, the deposit distribution components 320 may bepre-configured to execute periodic transfers from the main accountbalance to the sub-account balance. Such transfers may be set up by theaccount holder when the account is opened.

FIG. 5 is flow chart illustrating a method for making deposits into afinancial inclusion account in accordance with an embodiment of theinvention. The method begins in S500 and a deposit is received in S502.In S504, the financial account management system 200 determines if thedeposit is eligible to be split between the main account and thenecessities sub-account. If the payment is not eligible to be split inS504, the financial account management system credits the main accountbalance with the funds in S512. If the deposit is eligible for the splitin S504, the system applies stored rules to determine the appropriatesplit in S510. In S520, the financial account management system creditsthe main account and the necessities sub-account in accordance with thedetermined split.

FIG. 4 is a block diagram illustrating a withdrawal engine 400 of thefinancial inclusion account system 200 in accordance with an embodimentof the invention. The withdrawal engine 400 may include authorizationcomponents 410, balance determination component 420, withdrawal module430, and stored withdrawal rules 440. In operation, the authorizationcomponents 410 may consult stored withdrawal rules 440 to determine ifthe party requesting withdrawal is an approved debit requestor. As setforth above, in embodiments of the invention, an approved debitrequestor must both be deemed eligible by the service recipientfinancial institution and be authorized by the service recipient accountholder in order to become an approved debit requestor. Balancedetermination component 420 may determine if sufficient balance existsin the necessities sub-account in order to satisfy the withdrawalrequest. The withdrawal module 430 may withdraw the requested amount ora determined alternative account based on the stored withdrawal rules440.

In embodiments of the invention, sub-account funds can be removed onlyby the account holder and by approved direct debit requesters throughthe direct debit process. The sub-account funds may be associated with aunique address accessible only to these approved debit requestors. Theunique address of the sub-account may be achieved through the use of aunique account number or alternatively, the account number may be thesame as the main account number, but a separate unique identifier may beprovided.

As set forth above, in embodiments of the invention, withdrawal from thenecessities sub-account is regulated both by eligibility as determinedby the financial institution, and authorization, as determined by theaccount holder. Thus, in order to create stored withdrawal rules 440,the eligibility list of the financial institution may be reconciled withan authorization list for each account holder to create a unique set ofwithdrawal rules for each account holder.

In an alternative embodiment, the eligibility list created by thefinancial institution and the authorization list created by the accountholder remain as separate lists, thus creating a two-tiered filter. Inthis embodiment, upon each deposit request, the withdrawal enginedetermines if the debit requestor is on both lists. Unless the debitrequestor is on both lists, the debit requester will be unable towithdraw funds from the necessities sub-account.

In alternative embodiments of the invention, the withdrawal rules 440may be based solely on the eligibility determination made by thefinancial institution. In this embodiment, eligible service providersare entitled to withdraw from the necessities sub-account withoutexplicit account holder authorization. Thus, when setting up theaccount, the account holder is made aware of the identities of eligibledirect debit requests.

If insufficient funds are available in the necessities sub-account, thewithdrawal module 430 may be required by the withdrawal rules 440 towithdraw additional funds from the main balance, or alternatively toreject the request for withdrawal of additional funds.

FIG. 6 is a flow chart illustrating a method for paying direct debitsfrom the financial inclusion account in accordance with an embodiment ofthe invention. The method begins in S600 and a direct debit request isreceived in S602. In S604, the financial account management systemdetermines if the direct debit request is from an eligible and/orauthorized provider.

If in S604, if the system determines that the direct debit request isnot from an eligible and/or authorized provider, the system furtherdetermines whether the main account balance includes sufficient funds inS620. If the main account balance contains sufficient funds to satisfythe direct debit request in S620, then the request is satisfied throughpayment in S624. If the main balance does not contain sufficient fundsto satisfy the request in S620, the direct debit request is declined inS630. As set forth above, alternative embodiments may decline theineligible debit requester transaction without checking the mainbalance.

If in S604, the direct debit request came from an eligible and/orauthorized provider, the financial management system determines in S610whether the necessities sub-account contains sufficient funds to satisfythe request. If the necessities sub-account does not contain sufficientfunds in S610, the system declines the direct debit in S630.Alternatively, in other embodiments, the system may check the mainbalance for satisfaction of the debit request. If the necessitiessub-account contains sufficient funds in S610, the direct debit requestis satisfied from the necessities sub-account in S614.

In alternative embodiments of the invention, if the necessitiessub-account does not include sufficient funds to satisfy the request,then the request for a withdrawal may be denied.

FIG. 7 is a diagram illustrating a stored withdrawal rule table 700 inaccordance with an embodiment of the invention. As explained above withrespect to FIG. 4, withdrawal rules may be created based on eligibilityas determined by the financial institution and based on authorization asdetermined by the account holder. In embodiments of the invention, thewithdrawal engine 400 preferably includes or consults with such a tableprior to allowing a direct debit transaction. The stored withdrawalrules table 700 may include a provider identifier 710, a providerauthorized debit amount 720, an authorized debit frequency 730, andoptionally, a provider priority 740. Unless a provider is both eligibleand authorized the provider's identifier will not appear on the storedwithdrawal rules table 700. In embodiments of the invention, instead ofa debit amount 720, a percentage may be provided for determining anamount to be drawn from the sub-account. In such embodiments, theremaining amount could be withdrawn from the main account.

FIG. 8 is block diagram illustrating a stored deposit rule table 800 inaccordance with an embodiment of the invention. The stored deposit rule800 may include a depositor identifier 810 for each depositor, apercentage of funds to be deposited in the main account at 820, and apercentage of funds to deposited in the necessities sub-account at 830.As an alternative to percentages, specific authorized deposit andwithdrawal amounts may be stored.

FIG. 9 is a block diagram illustrating a service provider billingmanagement system in accordance with an embodiment of the invention. Theservice provider may re-determine the debit amount based on whether therequested direct debit is approved. Thus, a service provider billingmanagement system 900 may include price decision rules 910 interactingwith direct debit determination components 920.

The components shown in FIGS. 1-4 and 7-9 above may be or include acomputer or multiple computers. Although the components are shown asdiscrete units, all components may be interconnected or combined. Thecomponents may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by one or more computers to perform the procedures shown in theappended flowcharts as well as other procedures described herein.Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types.

Those skilled in the art will appreciate that the invention may bepracticed with various computer system configurations, includinghand-held wireless devices such as mobile phones or PDAs, multiprocessorsystems, microprocessor-based or programmable consumer electronics,minicomputers, mainframe computers, and the like. The invention may alsobe practiced in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote computer storage mediaincluding memory storage devices.

The computer system may include a general purpose computing device inthe form of a computer including a processing unit, a system memory, anda system bus that couples various system components including the systemmemory to the processing unit.

Computers typically include a variety or computer readable media thatcan form part of the system memory and be read by the processing unit.By way of example, and not limitation, computer readable media maycomprise computer storage media and communication media. The systemmemory may include computer storage media in the form of volatile and/ornonvolatile memory such as read only memory (ROM) and random accessmemory (RAM). A basic input/output system (BIOS), containing the basicroutines that help to transfer information between elements, such asduring start-up, is typically stored in ROM. RAM typically contains dataand/or program modules that are immediately accessible to and/orpresently being operated on by processing unit. The data or programmodules may include an operating system, application programs, otherprogram modules, and program data. The operating system may be orinclude a variety of operating systems such as Microsoft Windows®operating system, the Unix operating system, the Linux operating system,the Xenix operating system, the IBM AIX™ operating system, the HewlettPackard UX™ operating system, the Novell Netware™ operating system, theSun Microsystems Solaris™ operating system, the OS/2™ operating system,the BeOS™ operating system, the Macintosh™ operating system, the Apache™operating system, an OpenStep™ operating system or another operatingsystem of platform.

At a minimum, the memory includes at least one set of instructions thatis either permanently or temporarily stored. The processor executes theinstructions that are stored in order to process data. The set ofinstructions may include various instructions that perform a particulartask or tasks, such as those shown in the appended flowcharts of FIGS. 5and 6. Such a set of instructions for performing a particular task maybe characterized as a program, software program, software, engine,module, component, mechanism, or tool. The financial inclusion accountsystem 200 may include a plurality of software processing modules storedin a memory as described above and executed on a processor in the mannerdescribed herein. The program modules may be in the form of any suitableprogramming language, which is converted to machine language or objectcode to allow the processor or processors to read the instructions. Thatis, written lines of programming code or source code, in a particularprogramming language, may be converted to machine language using acompiler, assembler, or interpreter. The machine language may be binarycoded machine instructions specific to a particular computer.

Any suitable programming language may be used in accordance with thevarious embodiments of the invention. Illustratively, the programminglanguage used may include assembly language, Ada, APL, Basic, C, C++,COBOL, dBase, Forth, FORTRAN, Java, Modula-2, Pascal, Prolog, REXX,and/or JavaScript for example. Further, it is not necessary that asingle type of instruction or programming language be utilized inconjunction with the operation of the system and method of theinvention. Rather, any number of different programming languages may beutilized as is necessary or desirable.

Also, the instructions and/or data used in the practice of the inventionmay utilize any compression or encryption technique or algorithm, as maybe desired. An encryption module might be used to encrypt data. Further,files or other data may be decrypted using a suitable decryption module.

The computing environment may also include other removable/nonremovable,volatile/nonvolatile computer storage media. For example, a hard diskdrive may read or write to nonremovable, nonvolatile magnetic media. Amagnetic disk drive may read from or writes to a removable, nonvolatilemagnetic disk, and an optical disk drive may read from or write to aremovable, nonvolatile optical disk such as a CD ROM or other opticalmedia. Other removable/nonremovable, volatile/nonvolatile computerstorage media that can be used in the exemplary operating environmentinclude, but are not limited to, magnetic tape cassettes, flash memorycards, digital versatile disks, digital video tape, solid state RAM,solid state ROM, and the like. The storage media are typically connectedto the system bus through a removable or non-removable memory interface.

The processing unit that executes commands and instructions may be ageneral purpose computer, but may utilize any of a wide variety of othertechnologies including a special purpose computer, a microcomputer,mini-computer, mainframe computer, programmed micro-processor,micro-controller, peripheral integrated circuit element, a CSIC(Customer Specific Integrated Circuit), ASIC (Application SpecificIntegrated Circuit), a logic circuit, a digital signal processor, aprogrammable logic device such as an FPGA (Field Programmable GateArray), PLD (Programmable Logic Device), PLA (Programmable Logic Array),RFID processor, smart chip, or any other device or arrangement ofdevices that is capable of implementing the steps of the processes ofthe invention.

It should be appreciated that the processors and/or memories of thecomputer system need not be physically in the same location. Each of theprocessors and each of the memories used by the computer system may bein geographically distinct locations and be connected so as tocommunicate with each other in any suitable manner. Additionally, it isappreciated that each of the processor and/or memory may be composed ofdifferent physical pieces of equipment.

A user may enter commands and information into the computer through auser interface that includes input devices such as a keyboard andpointing device, commonly referred to as a mouse, trackball or touchpad. Other input devices may include a microphone, joystick, game pad,satellite dish, scanner, voice recognition device, keyboard, touchscreen, toggle switch, pushbutton, or the like. These and other inputdevices are often connected to the processing unit through a user inputinterface that is coupled to the system bus, but may be connected byother interface and bus structures, such as a parallel port, serialport, game port or a universal serial bus (USB).

One or more monitors or display devices may also be connected to thesystem bus via an interface. In addition to display devices, computersmay also include other peripheral output devices, which may be connectedthrough an output peripheral interface. The computers implementing theinvention may operate in a networked environment using logicalconnections to one or more remote computers, the remote computerstypically including many or all of the elements described above.

Various networks may be implemented in accordance with embodiments ofthe invention, including a wired or wireless local area network (LAN)and a wide area network (WAN), wireless personal area network (PAN) andother types of networks. When used in a LAN networking environment,computers may be connected to the LAN through a network interface oradapter. When used in a WAN networking environment, computers typicallyinclude a modem or other communication mechanism. Modems may be internalor external, and may be connected to the system bus via the user-inputinterface, or other appropriate mechanism. Computers may be connectedover the Internet, an Intranet, Extranet, Ethernet, or any other systemthat provides communications. Some suitable communications protocols mayinclude TCP/IP, UDP, or OSI for example. For wireless communications,communications protocols may include Bluetooth, Zigbee, IrDa or othersuitable protocol. Furthermore, components of the system may communicatethrough a combination of wired or wireless paths.

Thus, in accordance with embodiments of the invention, acomputer-implemented system and method are provided for facilitatingefficient savings management and payment for necessities.

While particular embodiments of the invention have been illustrated anddescribed in detail herein, it should be understood that various changesand modifications might be made to the invention without departing fromthe scope and intent of the invention.

From the foregoing it will be seen that this invention is one welladapted to attain all the ends and objects set forth above, togetherwith other advantages, which are obvious and inherent to the system andmethod. It will be understood that certain features and sub-combinationsare of utility and may be employed without reference to other featuresand sub-combinations. This is contemplated and within the scope of theappended claims.

1. A computer-implemented financial inclusion account system provided bya financial institution for facilitating payments between systemparticipants, the system participants including account holder servicerecipients and eligible necessities service providers, the systemcomprising: at least one financial inclusion account maintaining fundsfor an account holder service recipient, the financial inclusion accountincluding a main account having a main account balance and at least onesub-account having a sub-account balance, the at least one sub-accountstoring funds for payment to at least one eligible necessities serviceprovider; withdrawal rules stored in a memory the withdrawal rulesincluding identification of at least one approved debit requester forwithdrawing funds from the sub-account balance, the withdrawal rulesrequiring approved debit requesters to be debit requesters designated bythe financial institution as eligible necessities service providers; anda withdrawal engine for accessing the stored withdrawal rules uponreceiving a debit request, the withdrawal engine causing the sub-accountbalance to be debited if the debit requester is an approved debitrequestor according to the stored withdrawal rules.
 2. The system ofclaim 1, wherein the withdrawal rules define approved debit requestorsas debit requestors deemed eligible necessities providers by the servicerecipient financial institution to execute direct debit requests fromthe sub-account balance.
 3. The system of claim 2, wherein thewithdrawal rules define approved debit requesters as debit requestersauthorized by the service recipient account holder to execute directdebit requests from the sub-account balance.
 4. The system of claim 1,further comprising a deposit engine for depositing funds to eachsub-account balance.
 5. The system of claim 4, wherein the depositengine comprises depositor verification components, the depositorverification components accessing stored deposit rules to verifydepositor identity.
 6. The system of claim 5, wherein the deposit enginefurther comprises deposit distribution components for distributing adeposit amount to the sub-account balance based on the stored depositrules.
 7. The system of claim 5, wherein the stored deposit rulesfurther comprises a provider authorized debit percentage for allocatingto the sub-account balance.
 8. The system of claim 1, wherein thewithdrawal engine comprises a balance determination component fordetermining whether the sub-account has a sufficient balance forsatisfying each debit request.
 9. The system of claim 1, wherein thestored withdrawal rules further comprise a provider authorized debitamount associated with a provider identifier.
 10. The system of claim 8,wherein the stored withdrawal rules further comprise aprovider-authorized debit frequency for determining a minimum timeinterval for allowing debit requests from an identified debit requester.11. A computer-implemented financial inclusion account management methodprovided by a financial institution for facilitating payments betweensystem participants, the system participants including account holderservice recipients and eligible necessities service providers, themethod comprising: establishing at least one financial inclusion accountmaintaining funds for an account holder service recipient, the financialinclusion account including a main account having a main account balanceand at least one sub-account having a sub-account balance, the at leastone sub-account storing funds for payment to at least one eligiblenecessities service provider; storing withdrawal rules in a memory, thewithdrawal rules including a listing of approved debit requestorswherein approved debit requestors have been designated by the financialinstitution as eligible necessities service providers; accessing thestored withdrawal rules implementing a withdrawal engine upon receivinga debit request the withdrawal engine causing the sub-account balance tobe debited it the debit requester is an approved debit requester. 12.The method of claim 11, further comprising defining approved debitrequesters as debit requestors deemed eligible necessities providers bythe service recipient financial institution to execute direct debitrequests from the sub-account balance.
 13. The method of claim 12,further comprising defining approved debit requestors as debitrequestors authorized by the service recipient account holder to executedirect debit requests from the sub-account balance.
 14. The method ofclaim 11, further comprising implementing a deposit engine fordepositing funds to each sub-account balance.
 15. The method of claim14, further comprising accessing stored deposit rules to verifydepositor identity with depositor verification components.
 16. Themethod of claim 15, wherein the deposit engine distributes a depositamount to the sub-account balance based on the stored deposit rulesusing deposit distribution components.
 17. The method of claim 15,further comprising determining a provider authorized debit percentagefor allocating to the sub-account balance.
 18. The method of claim 11,further comprising determining whether the sub-account has a sufficientbalance for satisfying each debit request implementing a balancedetermination component.
 19. The method of claim 11, further comprisingdefining a provider authorized debit amount associated with a provideridentifier in the stored withdrawal rules.
 20. The method of claim 18,further comprising defining a provider-authorized debit frequency in thestored withdrawal rules for determining a minimum time interval forallowing debit requests from an identified debit requestor.
 21. Acomputer-implemented financial inclusion account system for facilitatingpayments between system participants, the system participants includingservice recipients and eligible necessities service providers, thesystem comprising: at least one financial inclusion account, theFinancial inclusion account including a main account having a mainaccount balance and at least one sub-account having a sub-accountbalance, the at least one sub-account storing funds for payment to atleast one eligible necessities service provider; and a financialinclusion account management system for managing the at least onefinancial inclusion account, the management system comprising awithdrawal engine and a deposit engine, the deposit engine accessingstored deposit rules in order to determine a main balance deposit amountof a submitted deposit to credit to the main balance and a sub-accountdeposit amount of the submitted deposit to credit to the sub-account,the withdrawal engine comprising authorization components for consultingwithdrawal rules to determine if a debit requester is an approved debitrequester for withdrawing funds from the sub-account, wherein eachapproved debit requester is designated by the financial institution asan eligible necessities service provider, and a withdrawal module forexecuting withdrawal from the sub-account for the approved debitrequester.
 22. The system of claim 21, wherein the withdrawal rules arestored in a memory and include identification of approved debitrequesters having approval for withdrawing funds from the sub-accountbalance, the withdrawal rules defining approved debit requesters asdebit requestors designated both as eligible requesters by the financialinstitution and as authorized requesters by the account holder.
 23. Thesystem of claim 21, wherein the deposit engine comprises depositorverification components, the depositor verification components accessingstored deposit rules to verify depositor identity.
 24. The system ofclaim 22, wherein the stored deposit rules further comprise anauthorized deposit percentage for allocating to the sub-account balance.25. The system of claim 21, wherein the withdrawal engine comprises abalance determination component for determining whether the sub-accounthas a sufficient balance for satisfying each debit request.
 26. Thesystem of claim 21, wherein the stored withdrawal rules further comprisean authorized debit amount associated with a provider identifier. 27.The system of claim 21, wherein the stored withdrawal rules furthercomprise an authorized debit frequency for determining a minimum timeinterval for allowing debit requests from an identified debit requestor.28. A computer-implemented financial inclusion account management methodfor facilitating payments for approved services between systemparticipants, the system participants including service recipients andapproved necessities service providers, the account management methodcomprising: providing at least one financial inclusion account, thefinancial inclusion account including a main account having a mainaccount balance and at least one sub-account having a sub-accountbalance, the at least one sub-account storing funds for payment to atleast one approved necessities provider; and managing deposits andwithdrawals to and from the at least one financial inclusion account,the management of deposits comprising storing deposit rules; accessingthe stored deposit rules upon receiving a deposit in order to determinea main balance deposit amount of a submitted deposit to credit to themain balance and a sub-account deposit amount of the submitted depositto credit to the sub-account, and executing the stored deposit rules tocredit the submitted deposit to at least one of the main balance and thesub-account balance; the management of withdrawals comprising; storingwithdrawal rules including rules determining approval for executingwithdrawals from the sub-account; consulting withdrawal rules todetermine if a debit requestor is an approved debit requester forwithdrawing funds, wherein each approved debit requester is designatedby the financial institution as an eligible necessities serviceprovider, and executing withdrawal from the sub-account for approveddebit requestors.
 29. The method of claim 28, further comprisingdefining approved debit requestors as debit requesters deemed eligibleby the service recipient financial institution to execute direct debitrequests from the sub-account balance and as debit requesters authorizedby the service recipient account holder to execute direct debit requestsfrom the sub-account balance.
 30. The method of claim 28, furthercomprising accessing stored deposit rules to verify depositor identitywith depositor verification components.
 31. The method of claim 28,further comprising determining whether the sub-account has a sufficientbalance for satisfying each debit request implementing a balancedetermination component.